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Remarks 

1. Claims 1-34 and 36-38 were pending. Claims 1, 28-33, 36, and 38 have been 
amended. Claim 34 has been canceled. No new claims have been added. Therefore, claims 
1-33 and 36-38 remain pending. Applicants respectfully request reconsideration of the 
claims in view of the above amendments and the following remarks. 

2. The Examiner rejected claims 1, 3-14, 17-20, 25-27, 29-34, and 36-38 under 35 
U.S.C. 102(b) as being anticipated by Wolff. The Examiner rejected claims 2, 15-16, 21, and 
28 under 35 U.S.C. 103(a) as being unpatentable over Wolff in view of Ravishankar. The 
Examiner rejected claims 22-23 under 35 U.S.C. 103(a) as being unpatentable over Wolff in 
view of Hanson. The Examiner rejected claim 24 under 35 U.S.C. 103(a) as being 
unpatentable over Wolff in view of Hanson and Oracle. 

Independent claims 1,14, 29, 30, 31, 32, 36, 37, and 38 relate generally to techniques 
for automatically building electronic forms based on data capture definitions, whereas Wolff 
discloses a technique for displaying a series of forms related to a selected task. 

In Wolff, the system determines which of a given series of forms to display when 
associated with completing a task object (see FIG. 3, step 108). As discussed at column 8, 
lines 5-10 of Wolff, a series of pointers to forms to be used for a particular task results in the 
forms being "retrieved from memory." Therefore, Wolffs forms are not determined during 
runtime according to a hierarchical structure of elements defined in a data capture definition 
file as in the presently claimed invention. 

In Wolffs "form generating system" shown in Figure 4, Wolff teaches only that the 
fields required for a form are determined by pointers to the various "form.field" or 
"form.segment" objects contained in the object slots. See Wolff, col. 9, lines 1-4. The 
system causes the fields that must be completed to be sequentially "set off or highlighted" 
for a task to be completed. See Wolff, col. 9, lines 14-20. If data is entered that requires 
additional fields to be filled in, these are displayed. See Wolff, col. 9, line 45. The data 
elements described in Wolff are limited to a single, specific execution purpose. Any 
additional fields that are to be filled in are merely called up from a previously existing task 
structure. As stated, the end-user only perceives that he or she is filling out a single form. 
See Wolff, col. 5, line 38. In reality, the hierarchical object oriented programming of Wolff 
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merely allows multiple forms in different databases to be completed with the same 
information, but the forms preexist prior to the information being entered. 

Thus, Wolffs "form generating system" does not actually generate the forms during 
runtime and does not teach or otherwise suggest that form layout and physical positioning of 
user input areas should be determined during runtime. Furthermore, Wolff does not teach 
that the layout and physical positioning of user input areas in the form is determined by the 
logical hierarchical structure defined in any data capture definition file, and does not suggest 
that this should happen for each form. The "task map" hierarchical structure of Wolff refers 
to the sequence of the forms to be filled out. See Wolff, col. 8, lines 13-20. In contrast, the 
hierarchical structure of the claimed invention is used to automatically determine the layout 
of the visual displays for each form (see, for example, page 21, lines 1-8). 

Additional evidence that Wolff fails to address every claim limitation of the 
Application be found in Wolffs figures. Figure 6 indicates that a pre-designed layout of 
display is used, in which the pre-designed form 378 to be displayed is windowed within a 
larger display 375. See Wolff, Fig. 6. The display 386 also displays a task map 386 that lists 
the forms that have to be filled out to complete the designated task. Id. 

Therefore, it can be readily seen that the task 60 of Figure 2 causes to be displayed in 
window 375 of Figure 6 a list of forms (in a predetermined window layout) that need to be 
filled in for a task to be completed. The forms are successively displayed in window 378. 
The layout and physical positioning of user input areas on each display and form are not 
determined at runtime but rather have already been determined by the predefined window 
375 layout and the predetermined embedded form layout that is inserted into window 378. 

It appears that the only runtime configuration of a display that takes place in Wolff is 
highlighting of fields that are important to the task or which have to be filled in to complete 
the form for that task. See Wolff, col. 10, line 65 to col. 11, line 3. This is fundamentally 
different than the presently claimed invention, in which the form layout and physical 
positioning of the user input areas on each display are determined, during runtime of the data 
capture process from information in the data capture definition file, in a manner 
corresponding to the defined logical hierarchical structure. 

Independent claims 1, 29, 30, 32, 36, and 38 have been amended to clarify that each 
visual display has an automatically determined form layout comprising a plurality of user 
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input areas corresponding to the data elements, in which the form layout and physical 
positioning of the user input areas on each display are determined, during runtime of the data 
capture process from information in the data capture definition file, in a manner 
corresponding to the defined logical hierarchical structure. As discussed above, Applicants 
respectfully submit that Wolff fails to teach or otherwise suggest these and other claim 
elements. Applicants further submit that Ravishankar, Hanson, Oracle, and the other 
references made of reference fail to teach or otherwise suggest at least these claim elements. 
Thus, Applicants respectfully submit that the pending claims are allowable over Wolff both 
alone and in combination with Ravishankar, Hanson, and Oracle. 

3. The Examiner rejected claim 5 under 35 U.S.C. 1 12, second paragraph, as being 
indefinite due to the term "output message format." 

Applicants respectfully submit that the expression "output message format" is clear 
based on the specification as filed. Definiteness of claim language must be analyzed in light 
of the content of the particular application disclosure. MPEP § 2173.02. In the subject 
patent application, the data capture file 17 specifies the data elements 13, 103 (e.g. name, 
address, date of birth, occupation, as shown in figure 10) and their hierarchical structure (e.g. 
how the elements 103 fall within a section 102 such as personal details or within a subsection 
104). This data capture definition file has a predetermined format (e.g. XML), for example, 
as in claims 1 and 2. 

When actual data is captured (e.g. a user enters data corresponding to each of the 
required data elements), that data has to be formatted according to a data model standard so 
that it can be used by other systems that adhere to the same data model (see, for example, 
page 15, line 28 to page 16, line 2 of the subject patent application). The captured data is 
referred to as the "message" (see, for example, page 25, line 2 of the subject patent 
application) which is output from the data capture process and has a format that adheres to 
the data model standard (see, for example, page 15, line 28 to page 16, line 2 of the subject 
patent application). This clearly defines an "output message format." 

4. The Examiner rejected claim 28 under 35 U.S.C. 1 12, second paragraph, as being 
dependent upon itself. 
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Claim 28 has been amended to be dependent upon claim 27. 

5. The Examiner objected to the specification as failing to provide proper antecedent 
basis for a "computer readable medium" in line 2 of claim 33. 

As discussed in MPEP 2163, a patent specification must describe the claimed 
invention in sufficient detail that one skilled in the art can reasonably conclude that the 
inventor had possession of the claimed invention. For an original claim, there is a strong 
presumption that an adequate written description of the claimed invention is present when the 
application is filed (Applicants note that the original claims are part of the specification and 
therefore form part of the disclosure). The subject patent application describes a software 
application 30 that performs various functions associated with the claimed invention. It 
certainly would have been understood by one of ordinary skill in the art at the time the 
invention was made that a software application includes computer program code that can be 
stored on a computer readable medium and loaded onto a computer so as to make the 
computer execute the programmed functions. Thus, Applicants respectfully submit that the 
specification provides adequate support for the claim term "computer readable medium." 

Claim 33 has been amended as to form and also to clarify that the computer readable 
medium is a tangible computer readable medium. 

6. The Examiner objected to the specification as failing to provide proper antecedent 
basis for "electronic data transmission" in lines 1-2 of claim 34. 

Claim 34 has been canceled without prejudice. 

7. The Examiner objected to claims 29 and 38 for including erroneous text. 
Claims 29 and 38 have been amended to remove the erroneous text. 

8. As detailed above, Applicant respectfully submits that the pending claims are novel 
and non-obvious over the prior art. Applicant submits that the present application is in 
condition for allowance and early notice to that effect is respectfully solicited. If any matters 
remain outstanding, the Examiner is requested to telephone the undersigned so that they may 
be resolved expeditiously. 
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9. Applicant petitions for a two month extension of time. In the event that a further 
extension is needed, this conditional petition of extension is hereby submitted. Applicant 
requests that deposit account number 19-4972 be charged for any fees that may be required 
for the timely consideration of this application. 



Respectfully submitted, 

/Jeffrey T. Klayman. #39.250/ 
Jeffrey T. Klayman 
Reg. No. 39,250 
Attorney for Applicants 

Bromberg & Sunstein LLP 
125 Summer Street, 1 1 th Floor 
Boston, MA 02 11 0-1 61 8 
(617) 443-9292 
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